Traditional client-server systems employ a two-tiered architecture such as that illustrated in FIG. 1. Applications 102 executed on the client side 100 of the two-tiered architecture are comprised of a monolithic set of program code including a graphical user interface component, presentation logic, business logic and a network interface that enables client 100 to communicate over network 103 with one or more servers 101. A database 104 maintained on server 101 provides non-volatile storage for the data accessed and/or processed by application 102.
As is known in the art, the “business logic” component of the application represents the core of the application, for example, the rules governing the underlying business process (or other functionality) provided by the application. The “presentation logic” describes the specific manner in which the results of the business logic are formatted for display on the user interface. The “database” 104 includes data access logic used by the business logic to store and retrieve data.
The limitations of the two-tiered architecture illustrated in FIG. 1 become apparent when employed within a large enterprise. For example, installing and maintaining up-to-date client-side applications on a large number of different clients is a difficult task, even with the assistance of automated administration tools. Moreover, a tight coupling of business logic, presentation logic and the user interface logic makes the client-side code very brittle. Changing the client-side user interface of such applications is extremely hard without breaking the business logic, and vice versa. This problem is aggravated by the fact that, in a dynamic enterprise environment, the business logic may be changed frequently in response to changing business rules. Accordingly, the two-tiered architecture is an inefficient solution for enterprise systems.
In response to limitations associated with the two-tiered client-server architecture, a multi-tiered architecture has been developed, as illustrated in FIG. 2. In the multi-tiered system, presentation logic 221, business logic 222 and database 223 are logically separated from the user interface 220. These layers are moved off of client 225 to one or more dedicated servers on network 203. For example, presentation logic 221, business logic 222, and database 223 may each be maintained on separate servers, 226, 227 and 228, respectively.
This separation of logic components and the user interface provides a more flexible and scalable architecture compared to that provided by the two-tier model. For example, the separation ensures that all clients 225 share a single implementation of business logic 222. If business rules change, changing the current implementation of business logic 222 to a new version may not require updating any client-side program code. In addition, presentation logic 221 may be provided which generates code for a variety of different user interfaces 220, which may be standard browsers such as Internet Explorer® or Netscape Navigator®.
Although the multi-tiered system illustrated in FIG. 2 provides a more flexible architecture, it also results in significant additional complexity. For example, the distributed nature of applications and components within the multi-tiered system makes it more complicated for the applications and components to communicate with each other. A class of middleware known as Message-Oriented Middleware may be used to facilitate communication between applications and components.
Message-Oriented Middleware (MOM) refers to computer software that provides a message service between software components or applications. The message service provided by MOM is often referred to as “loosely coupled” because a component sends a message to a destination and the recipient can retrieve the message from the destination. A message service typically includes a message provider and one or more clients. The message provider facilitates, for example, creating, sending, receiving, and reading messages. A client uses the message provider to, for example, send a message to a destination and another client may use the message provider to retrieve the message from the destination.
Although the message service facilitates communication between distributed software components and applications, it also reduces some of the flexibility of the multi-tiered architecture. For example, the scalability of the multi-tiered architecture may be constrained by the capacity of a central message provider. Also, a central message provider requires a relatively brittle namespace scheme to ensure that messages are properly delivered.